During my tenure at a large service provider, someone in the purchasing department decided that all network equipment purchases were commodities to be bid out like the purchasing of pencils, pens and paper. Suffice it to say that even fiber-optic cables were not then commodities, and certainly not IP routers and switches.

Fast forward to today, and little has changed. Instead of just two leading providers of routers, we may now have three (for carriers) and perhaps one or two others in the enterprise space.

No industry wants to be locked into a single-source supplier, and so service providers have worked hard on the technology, business relationships and standards fronts to foster multiple suppliers for these critical network infrastructure elements.

That hard work has saved service providers from the single-source (monopoly) dangers of one large and well-known vendor to now include suppliers like Juniper Networks and Alcatel-Lucent not just as a second source, but as solid primary source alternatives.

In switching we’ve seen some expansion of suppliers, but also some consolidation with acquisitions and consolidation in the industry. In Layer 4-7 network processing (load balancing, accelerators, etc.), we have seen significant growth in new vendors, such as full-function Layer 4-7 systems like A10 Networks, and smaller specialized vertical markets like accelerators for specific services.

The various “functions” of these elements — aggregation, distribution, forwarding, acceleration, security, etc. — are not icing on the cake. They are critical (if they cease to work, the Internet and IP networks would not function).

One notion of software-defined networking (SDN) is that controls for operating the network — and thereby rules for forwarding and other functions — should be centrally controlled and operated. Many operators and vendors still support this goal.

But in parallel with this and joining forces with the open source movement is a new SDN called software driven networking. The latter has a different meaning, focused less on the mechanics of forwarding (routing and forwarding) and more on operations and operational issues like provisioning, quality of service, etc.

The latter SDN is also more closed aligned with service implementation and could bridge the gap with network function virtualization (NFV) — for example, creating a an API for an application that might require server load balancing, acceleration, security (such as Virtual IPs) and even network systems like DNS.

With at least one school of thought moving away from the centralized control approach (which assumes commodity-driven hardware), there is at least some realization that the network with its component elements as commodities is not going to happen.

If vendors couldn't properly implement routing protocols in a distributed environment (i.e., the state-of-the-art current IP routing used on the Internet), how were they going to not only handle that, but also open their systems up to centralized control, and still work?

Many of the vendors pushing the former SDN agenda were looking for a way to break into the mark dominated by a few top-tier vendors. It now seems ever less likely that will happen. Instead, many of those vendors will be relegated to NFV functions within the enterprise (or within the data center even for service providers).

But at least the latter SDN could remain compatible with true distributed-system IP routing, relegating itself to some Layer 3 functions (not necessarily routing, but forwarding — for example, QoS and queuing). But more importantly, it could relegate to higher layers where there is no real centralized or distributed system for the management of so called Layer 4-7 (transport, session, presentation and application) functions.

Whether even the latter SDN (software driven networking) truly takes on all aspects of operations (including provisioning) remains to be determined.